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(54) Method of operation for an image processing apparatus 



(57) The invention relates to a method of operation 
of an image processing apparatus having a controller 
(74) anda plurality of resources (104, 106, 108) arranged 
in an arbitrary configuration. Each of the resources 
(1 04, 1 06. 1 08) provides an associated processor storing 
data related to operational capabilities of the associated 
resource. The controller (74) is adapted to dynamically 
configure the image processing apparatus to operate in 
accordance with the operational capabilities of each of 
the processors by defining job requirements as a com- 
bination of images defining a set of sheets and specify- 
ing compilations of sheets. The job requirement is con- 
verted into an assembly tree relationship for merging in- 
to additional assembly trees for formulating the job re- 
quirement. The controller (74) responds to the data re- 



lated to the operational capabilities of each of the mod- 
ules (104,106,108) and to the assembly tree relation- 
ship of images, copy sheets, and compilations of copy 
sheets for providing a production tree relationship of the 
operational capabilities of the modules (104,106,108) 
including timing relationships for operating the Image 
processing apparatus. The production tree relationship 
further permits arbitrary definition of a job requirement 
into a first segment independent of the capabilities of 
the modules and a second segment dependent upon se- 
lected capabilities of selected modules to allow the im- 
age processing apparatus to be partially configured 
based upon operator entered constraints. This tech- 
nique further allows adaptive control of selective diag- 
nostics. 
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Description 

The present invention relates to a method of oper- 
ation for an image processing apparatus and to a sys- 
tem for developing Document Output Terminals from au- 
tonomous machine modules with standard control, data 
communication and physical interfaces. 

US-A-5,363, 1 75, assigned to the same assignee as 
the present invention describes covering distributed job 
scheduling of modular components; and also European 
Patent Application No. 95 305 123.2 covers a controller 
interrogating processors for operational timing data for 
configuring the controller to operate in accordance with 
the operational timing of the processors. 

Traditionally, representing and controlling a ma- 
chine was based upon certain assumptions about the 
interconnection of the machine. In particular, the as- 
sumption was that a marker module was at the center, 
with feeders upstream and finishers downstream from 
the marker with the arrangement being essentially line- 
ar. Any deviations from this linear interconnection in the 
prior art were not possible, generally without substantial 
redesign of hardware and software. 

This type of product development usually began 
with a core machine, typically the marking engine, with 
modules were tailored to work with the core machine. 
This approach produced tightly integrated machines 
composed of modules that were functionally interde- 
pendent. The products may have been physically mod- 
ular (easily separable for transportation) but they were 
not easily reconfigured nor could they typically be used 
on other products without extensive revision of the con- 
trol software. With this type of development, it was dif- 
ficult to use modules with any product other than the 
product for which they were developed. In addition to 
the physical considerations, (for example, paper path 
heights, locations etc.) the modules generally have de- 
pendencies on other parts of the product, such as user 
interfaces, schedulers, and paper path control. 

For example, a machine module to staple a set of 
copy sheets was very specific to the machine hardware 
and software architecture. This meant that the set of 
copy sheets delivered to the stapler must be in a very 
well defined orientation and format. In this configuration, 
only one manner of stapling was accommodated. How- 
ever, with various stapling machines available from var- 
ious vendors, more information is needed from the var- 
ious staplers to determine if a particular operalbn can 
be completed. 

That is, one machine might receive the set face up, 
staple it, and deliver the set face down. Another machine 
might do the same but with the output face up, another 
machine might not take sets in but only separate sheets. 
Trying to describe all possible permutations using Doc- 
ument Printing Application (DPA) ISO 10175, styled key 
words quickly b com s unmanageable. Thus, ther has 
been a need to create modules that are capable of stand 
alone operation and are insensitive to the neighboring 



modules. 

It is possible to provide a system that treats all mod- 
ules uniformly regardless of specific functions (such as 
feeding, finishing, and marking) and to provide open 

5 configurations, that is, the number and sequence of 
modules is not fixed or limited. It is also possible to pro- 
vide each module with a generic, uniformly described 
identification that is conveyed to the controller and the 
controller in turn composes the descriptions into a single 

10 machine description. Thus, no nratter the geometric 
configuration of the connected modules, the machine 
operates to complete a given job. The configuration of 
the modules, feeder, marker, or finisher is not pertinent. 
There might not even be a marker present for a machine 

75 to operate and complete a job. In other words, there 
need not necessarily be only one marker or there need 
not be any marker and there may be any number of feed- 
ers or finishers to complete a given job requirement. Re- 
ferring to the above referenced applications, it is also 

20 possible to provide a system that treats various machine 
modules uniformly but with the appropriate constraints. 
In particular, it is possible to define modules as trans- 
ducers to accomplish coordination by finding a se- 
quence of transfers between the various transducer in- 

2S puts and outputs that is consistent with the constraints. 
To achieve modular uniformity and provide open 
configurations as discussed above, in particular, to de- 
fine modules as transducers and coordinate modules by 
finding a sequence of transfers between transducer in- 

30 puts and outputs that is consistent with constraints, 
there is a need to be able to represent job requirements 
or "documents"in a manner that accommodates this uni- 
formity. It is an object of the present invention, therefore, 
to provide a representation of a job requirement or 'doc- 

55 ument" that is machine independent and print ready. It 
is another object of the present invention to provide an 
assembly tree representation to describe a document in 
a universal manner rather than describing the document 
in terms of actions to be taken. 

40 There is also the need, however, to be able to de- 
scribe a document in a universal description and yet pro- 
vide a plan for an arbitrary document output tenminal to 
produce a particular job requirement or document. Once 
a job requirement has been expressed in a universal 

45 manner independent of specific modules to achieve the 
result, ultimately the document or job requirement must 
be produced by specified modules. 

It is therefore another object of the present invention 
to be able to map a universal representation of a job 

50 requirement along with an output terminal expressed in 
terms of components with capabilities onto the output 
terminals capabilities. Still another object of the present 
invention is to be able to convert an assembly tree rep- 
resentation of a job requirement into a production tree 

55 whos nodes represent output terminal capabilities and 
edges r present transfers of images, sheets, and com- 
pilations. Another object of the present invention is to 
s lectively provide partial or untimed production trees 
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to specily certain output terminal actions or selected di- 
agnostic routines. Still another object of the present in- 
vention is to be able to define a document with an as- 
sennbly tree component and a partial production tree 
component. 

According to the present invention, an electronic im- 
age processing apparatus is provided with a controller 
and a plurality of resources in an arbitrary configuration. 
Each of the resources includes an associated processor 
storing data related to operational capabilities of the as- 
sociated resource. The controller is adapted to dynam- 
ically configure the Image processing apparatus to op- 
erate in accordance with the operational capabilities of 
each of the processors and to define processing require- 
ments as a combination of images defining a set of 
sheets and specifying compilations of sheets. The 
processing requirement is converted into an assembly 
tree relationship for merging into additional assembly 
trees for formulating the job requirement. The controller 
r sponds to the data related to the operational capabil- 
ities of each of the modules and to the assembly tree 
relationship of images, copy sheets, and compilations 
of copy sheets for providing a production tree relation- 
ship of the operational capabilities of the modules in- 
cluding timing relationships for operating the image 
processing apparatus. The production tree relationship 
further permits arbitrary definition of a job requirement 
Into a first segment independent of the capabilities of 
the modules and a second segment dependent upon se- 
lected capabilities of selected modules to allow the im- 
age processing apparatus to be partially configured 
based upon operator entered constraints. This tech- 
nique further allows adaptive control of selective diag- 
nostics. 

The present invention will be described further, by 
way of examples, with reference to the accompanying 
drawings, in which: 

Figure 1 Is a simplified elevational view showing the 
relevant parts of a typical printing apparatus, on 
vtitch the present invention may operate; 
Figure 2 Is a systems diagram showing a typical pri- 
or art machine configuration; 
Figures 3. 4, and 5 illustrate arbitrary machine con- 
figurations capable of transparent control in accord- 
ance with the present invention; 
Figure 6 illustrates a universal controller in accord- 
ance with the present invention; 
Figure 7 illustrates a control architecture for the uni- 
versal controller of Figure 6 in accordance with the 
present invention; 

Figures 8 and 9 Illustrate machine representations 
as transducers with constraints in accordance with 
the present Invention; 

Figure 10 illustrates a typical assembly tree config- 
uration of a job requirement in accordance with the 
present invention; 

Figure 1 1 illustrates the m rging and transferring of 



4 

assembly trees between facilities in accordance 
with the present invention; and 
Figure 12 illustrates a typical production tree with 
constraints converted from an assembly tree to 
5 drive a printing apparatus in accordance with the 
present invention. 

Figure 1 is a simplified elevational view of the paper 
path of an on-demand printing apparatus, capable of 

10 simplex or duplex output, in which a stream of digital 
video signals representative of images desired to be 
printed causes the desired images to be formed on a 
selected side of a print sheet. The particular architecture 
shown in Figure 1 is for an electrostatographic printer, 

IS but it will be understood that the principle of the invention 
could apply equally to other types of image-creation 
technologies, such as ink-jet printing. The printing ap- 
paratus, generally Indicated as 10, contains one or more 
stacks of available sheets on which to print images. 

20 these stacks being indicated as 12a and 12b. The 
sheets of paper in ,the stacks 12a and 12b may differ in. 
for example, size, color, or the presence of a pre-printed 
letterhead. When it is desired to create an image on a 
sheet, a sheet of a desired type Is drawn from a stack 

2S such as 1 2a or 12b, such as by respective feeders 1 4a, 
1 4b, and the Individual sheet is fed onto duplex loop 1 6. 

Duplex loop 1 6 is typically in the form of an endless 
belt which Is capable, by means of friction, static elec- 
tricity, vacuum, or other means, of retaining a plurality 

30 of sheets thereon, thereby retaining a particular sheet 
until it Is time for the sheet to receive an Image on the 
side of the sheet facing outwardly from the belt of the 
duplex loop 16. In the architecture shown in Figure 1 , It 
is intended that sheets "ride" on the outer surface of the 

35 belt of duplex loop 16. Along one portion of duplex loop 
16, the belt of duplex loop 16 comes into close contact 
with a photoreceptor belt indicated as 18. At the point of 
close proximity of duplex loop 16 and photoreceptor belt 
18, there may be provided a transfer corotron 20, the 

40 function of which will be familiar to skilled in the art of 
xerography. 

In the xerographic-based embodiment of a printing 
apparatus shown In Figure 1, a device which shall be 
here generally referred to as an "imager" creates an 

45 electrostatic latent image on the surface of photorecep- 
tor 18. Imager 22 has the function of receiving a se- 
quence of digital signals representative of the desired 
image to be printed, and outputs a physical manifesta- 
tion, such as a modulated laser scanning beam, to im- 

50 agewise discharge selected areas on the photoreceptor 
18 to create an electrostatic latent image representativ 
of the image desired to be printed. As Is known in the 
art of electrophotography, other stations along the path 
of photoreceptor 1 8, such as a charging bar and devel- 

55 opment unit (not shown) are also required to create th 
desired developed image on the photoreceptor belt 18. 
This developed image, which is typically in the form of 
a reverse image In toner particles on the photoreceptor 
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1 8. is then made available to a sheet which rides on the 
outer surfac of duplex loop 16. 

After an Image is created on the photoreceptor belt 
1 8 by imager 22, and developed (by means not shown), 
the motion of photoreceptor belt 18 causes the devel- 
oped toner image to be in close proximity or in contact 
with a sheet, originally from stack 12a or 12b, which is 
riding on the outer surface of duplex loop 16. At transfer 
corotron 20, the toner particles arranged in imagewise 
fashion on photoreceptor 18 are electrostatically trans- 
ferred to the surface of the sheet by transfer corotron 
20. Soon thereafter along the path of duplex loop 16, 
the toner image on the sheet is passed through a f user 
24, which causes the toner image to be fixed perma- 
nently on the outer surface of the sheet, in a manner 
known in the art. Thus, immediately downstream of fus- 
er 24. there will be created a sheet having a desired im- 
age on the side thereof which faces outward along the 
duplex loop 1 6. If at this point the sheet having the image 
thereon is desired to be output from the system, a device 
such as router 26, a simple design of which is shown in 
Figure 1, but which may be of any number of designs 
known in the art, will cause the sheet to be disengaged 
from the duplex loop 1 6 and output from the printer such 
as through the path indicated by arrow 28. This output 
sheet can either be directly output into a tray for pickup 
by the user, or may be sent to a sorting or stapling device 
according to the larger architecture of the printing appa- 
ratus. 

It will be noted that the specifically electrostato- 
graphic aspects of the apparatus shown in Figure 1, 
such as the photoreceptor 18, imager 22, and transfer 
corotron 20, could be replaced by equivalent apparatus 
for other techniques for creating images on one side of 
a sheet, such as an ink-jet printhead. Also, imager 22 
as here described assumes that the user has unlimited 
control over the order of page images (the "digital vid- 
eo") being output through imager 22. If, however, the 
original source of images to be created is itself a set of 
automatically fed hard-copy images, i.e. if the printing 
system as a whole is operating as a copier, the feeding 
of originals will also create certain constraints on the op- 
timal order of images created with the printer It is prob- 
ably preferable to digitize (convert to digital signals) the 
original hard-copy images, electronically store the re- 
sulting data, and apply the data as required toadigitally- 
based imager 22 

Referring to Figure 2, there is shown a standard pri- 
or art interlace provided by a printer to attach feeding 
and/or finishing devices. In particular, marking engine 
or printer 40 including a user Interface with a screen is 
interconnected to document feeding device 42 and doc- 
ument finishing devices 46 and 48. As is well known, the 
feeding devices are sources of printable media like pa- 
per for providing printer 40 with stock for completion of 
the printing process. The finishing devices can b any 
suitable devices such as sorters, compilers, staplers, 
folders, or trimmers. Feeding devices are paper trays. 
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and the need for feeding devices is to supply an in- 
creased level of printable stock selection to th printer 
The feeding/finishing devices are physically at- 
tached to the print engine such that sheets can be feed 
5 Into the print engine or sheet or sets can be transferred 
from the print engine to the devices. The devices are 
attached to each other such that sheets or sets of paper 
can be transferred from one device to another 

Prior art devices are generally in a linear relation- 

^0 ship having one print engine with sheet feeder or internal 
trays up stream and a finisher station downstream as 
shown in Figure 2. A need exists to create modules that 
are capable of standalone operation and are not control 
dependent to their neighboring modules. The solution is 

IS developing autonomous machine modules with stand- 
ard control, data communication, and physical interfac- 
es, such that each module is indifferent to Its neighbor 
and all modules can be modeled using common tech- 
niques. Document Output Terminals would be created 

20 by integrating collections of physical machine modules. 
A machine module is standalone, and makes no as- 
sumptions about any other machine module, to enable 
a liberal mix-and-match of modules. An important as- 
pect of this approach is that all machine modules of a 

2S Document Output Terminal (DOT), whether finishers, 
markers, or finishers are treated identically, allowing 
nontraditional configurations such as feeders post- 
marking, tandem markers in series or parallel, feeders 
and finishers only with no marker, etc. as Illustrated in 

30 Figures 3. 4, and 5. 

For example. Figure 3 shows the two markers 50, 
52 in series with one feeder 54 and two finishers 56, 58. 
Figure 4 illustrates markers 60, 62 in parallel with finish- 
er 64 and no feeder module. Figure 5 illustrates a con- 

35 figuration of 3 feeders 66, 68, and 70 connected to fin- 
isher 72 and no marker module in the configurations. 
The only constraints on configurations is that the inputs 
and outputs of the machine modules must match (i.e. 
cant connect a module that outputs sets to a module 

^0 that only inputs sheets). 

Since machine modules or facilities can be config- 
ured Into arbitrary configurations, a small number of 
modules can yield a large number of configurations, 
each able to meet different needs of customers. For ex- 

^5 ample, a suite of ten modules might be used to create 
fifty different configurations to meet fifty different types 
of customer needs. Using autonomous machine mod- 
ules, this is reasonable; without autonomous machine 
modules it would be much more difficult to address to 

50 many different kinds of needs. Once a suite of machine 
modules has been developed, creating a new machine 
for a particular customer need can be orders of magni- 
tude faster In the ideal case, one simply selects which 
machine modules and how many of each are required, 

55 and ships them to th customers to be configured on 
site. In other cases, perhaps some modules already ex- 
ist but some module would need to be developed or 
adapted to operate as an autonomous machine module. 
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However, this is most likely still faster than developing 
an entirely new machine. 

A Mark Facility Controller manages, coordinates, 
and represents the entire connected configuration of 
feeder modules, marker modules, finisher modules and 
output modules. These are referred to collectively as 
Machine Modules. There is one Mark Facility Controller 
for a configuration of machine modules. This collection 
of machine modules along with a Mark Facility Control- 
ler is referred to as a Document Output Terminal or al- 
ternatively, a Mark Facility. 

The basic concept of the Mark Facility is that jobs 
coming from various sources such as decomposers, 
scanners, tile systems, etc. can be sent to a common 
Mark Facility interface independent of where the job is 
coming from, and independent of what physical ma- 
chine modules make up the DOT The Mark Facility Con- 
troller is responsible tor taking the mark job (described 
primarily via an Assembly Tree in accordance with the 
present invention) which is machine Independent, map- 
ping it on to the particular machine configuration 
present, and coordinating the machine modules to 
render the job. 

Note that the Mark Facility Controller is not respon- 
sible for the Image Path. However, the Mark Facility 
Controller interacts closely with an Image Loader The 
Image Loader is the demarcation point in the image path 
after which any further processing can be done in a de- 
terministic amount of time. From the point of view of the 
Mark Facility Controller, the Image Loader acts as an 
"image flow control valve", and the Mark Facility Con- 
troller coordinates the "feeding of images" through the 
Image Loader along with and in the same manner as 
the feeding sheets. 

Figures, illustrates how the Mark Facility Controller 
would interact with the various modules of the Mark Fa- 
cility as well as the client(s) of the Mark Facility Interface, 
In particular, there is shown a Mark Facility controller 74 
interconnected to arbitrary machine modules 76, 78, 
and 80 and image loader 82 by means of a page level 
control path shown as dashed lines at 84. Also shown 
connected to controller 74 are print server 86 and de- 
compose facility 87 interconnected by means of either 
a service level control path, 83 or job level control path 
88. Also, the image loader 82 can be connected be- 
tween decompose facility 87 and a marker module, such 
as 78 by means of a page level image path, dotted lines, 
90. Other operations such as a copy service, scan facil- 
ity, and file system can also be part of the system. The 
diagram is an example configuration, not the required 
configuration. The service level control path 83 provides 
control of the entire Mark Facility (e.g. suspend the fa- 
cility, resume the facility, submit mark job, cancel mark 
job, etc). The job level control path 88 would be used for 
streaming a job description (i.e. ass mbly tree); page 
I V I control 84 is ss ntially th sch duling of a page. 

The Mark Facility Controller meets various require- 
ments. In particular, the Mark Facility Controller ensures 



that the document output terminal produces what the 
operator asked for within the constraints of the DOT. If 
a jam or other anomaly (eg. crash) occurs during pro- 
duction then recovery must guarantee that no part of the 

5 output is lost or duplicated (e.g. cant lose or duplicate 
printed checks). The Mark Facility Controller ensures 
that the document output terminal is driven at rated 
speed whenever resources (paper, images) are availa- 
ble. This requirement implies that the Mark Facility Con- 

10 troller will control whatever buffering functions are nec- 
essary to ensure a steady supply of images to the mark- 
ing module regardless of peculiarities of page order re- 
quirements of specific modules. It further implies that the 
Mark Facility Controller must be capable of streaming 

IS mark job (the job description coming into the Mark Fa- 
cility Controller) to ensure uninterrupted delivery of 
prints. 

In addition, the Mark Facility Controller must sup- 
port a common Mark Facility Interface (software inter- 

20 face) for all DOTs; all DOTs are controlled through th 
same software interface, the Mark Facility Interface. Th 
Mark Facility Controller must provide a uniform Machine 
Module Interface for marking, feeding and finishing for 
all devices supported by the architecture The Mark Fa- 

2S cility Controller must provide information to enable Job 
Shop Scheduling (a.k.a. work flow management). This 
includes estimations of "time to complete job". This es- 
timation includes factors like skipped pitches which can 
be predicted and perhaps those that can be statistically 

30 predicted; it does not account for unpredictable skipped 
pitches (e.g. unexpected jams). The Mark Facility Con- 
troller also provides information to its clients to enable 
load balancing of print jobs across multiple DOTs. 

Also, the Mark Facility Controller makes available 

55 information about the DOT to Mark Facility clients, in- 
cluding information about the capabilities of the DOT 
and its current state. The Mark Facility Controller will not 
have any embedded knowledge about the client(s) of 
the Mark Facility Interface. That is there must not be any 

40 source dependencies incorporated into a Mark Facility 
Controller implementation. The Mark Facility Controller 
architecture has no a prior machine module specific 
knowledge. In particular, even if the Mark Facility Con- 
troller is physically packaged with a Marker Module, the 

45 Mark Facility Controller implementation software has no 
a priori knowledge of the marker module; it is completely 
independent of the marker module. Further, the under- 
lying technology of the Mark Facility Controller should 
be machine module independent as well. Note that a 

so particular implementation may be "tuned" or even "pre- 
set" for a certain set of configurations in order to de- 
crease resource requirements. 

The Mark Facility Controller has no knowledge of 
the image object content, processing requirements and 

ss r presentation. The Innage Loader 82 is responsible for 
p rforming Image proc ssing and the hard real time 
buffering, synchronization and transmission of data be- 
tween the Mark Facility Controller and the Marking Mod- 
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ule. Information about the production of a nnark job (e. 
g. skipped pitches, number of impressions, etc.) must 
be available to clients of the Mark Facility. The Mark Fa- 
cility Controller insulates clients of the Mark Facility from 
the timing dependencies of the machine modules. Also, 
the Mark Facility Controller is capable of job streaming 
- processing a new mark job while the current mark job 
(s) is being processed. The intent is to remain productive 
(i.e. do not "cycle down", minimize skip pitches) during 
the transition from the current job to the next. The Mark 
Facility Controller is capable of stream printing, that Is, 
of driving marking, feeding, and finishing modules be- 
fore the entire assembly tree or all source images have 
been received. 

Figure? Isahigh level architectural view of the Mark 
Facility Controller The control path is shown In solid ar- 
rows 1 1 2; the image path is shown In dotted arrows 1 02. 
The Mark Facility Controller 74 accepts mark job de- 
scriptions from a Mark Facility client such as a Print 
Service or Copy Service. The main component of this 
job is the assembly tree, which specifies the physical 
assembly of the document(s) to be produced. The as- 
sembly tree definition is independent of the DOT that 
will produce the job. The assembly tree references Im- 
ages which are stored outside of the Mark Facility Con- 
troller. Jobs are queued in the mark job queue 94, and 
then go to the scheduler 96 to begin execution. 

The scheduler understands and models the ma- 
chine modules In terms of capabilities and constraints 
which are uploaded Into the Mark Facility Controller at 
power up time and stored In the constraint store 110. 
The scheduler 96 coordinates the various machine 
modules ( 104, 106, 108, (e.g. feeder modules. Image 
path modules, marker modules, finisher modules, and 
output modules) to produce the job. The scheduler also 
coordinates the image loader 98 which is viewed by the 
scheduler as just another machine module (one that 
happens to feed images rather than paper). The image 
loader acts as a flow control" valve, pulling the images 
out of the image store and transferring them toa marking 
module at the scheduled time. Note that there are two 
fairly independent paths the control path and the im- 
age path. These two paths intersect at the image loader. 

The Mark Facility Controller accepts mark jobs and 
other communication from Mark Facility clients and con- 
trols the overall operation of the Machine Modules. 
There is one and only one Mark Facility Controller per 
configuration of machine modules; a machine module 
is controlled by exactly one Mark Facility Controller. A 
configuration of machine modules can have any combi- 
nation of modules including multiple mark engines (e.g. 
a color mark engine and a black/white mark engine both 
feeding into an envelope stuff er), or no mark engine (just 
f eders feeding directly into finishers). 

A key function of the Mark Facility Controller is to 
translate the configuration-independent and time-inde- 
pendent mark job specification into configuration-de- 
pendent and time-dependent actrans for the various ma- 



chine modules and to coordinate their activities. The 
Mark Facility Controller sees the machine modules as 
transducers which input and output work units (sheets. 
Images, and compilations) and have constraints on 
5 these inputs and outputs. Thus, mark scheduling in- 
volves planning and coordinating a timed sequence of 
matched inputs and outputs (I.e. transfers) between the 
various machine modules in the configuration. The Ma- 
chine Modules are responsible for translating timed se- 
10 quences of inputs and outputs for their module (e.g. ac- 
cept a sheet at time 3700 and an image at 4200, and 
output a print at time 8200) into the electrical and me- 
chanical events necessary to accomplish the transduc- 
tions to which they commit. Note that while machine 

15 modules talk to the fy/lark Facility Controller in terms of 
absolute time, this does not imply that machine control 
Inside a module must use absolute time. On the contra- 
ry, it Is anticipated that some machine modules will 
translate absolute time to machine clocks and base all 

20 their timing off machine ckx:ks as has been done tradi- 
tionally There exists a mechanism in the Machine Mod- 
ule Interface to keep absolute clocks in sync across ma- 
chine modules. 

The Mark Job Queue 94 holds jobs until they can 

2S be produced. Mark Facility clients can promote and de- 
mote jobs In the queue for additional flexibility. The 
Scheduler 96 takes in jobs represented as assembly 
trees from the job queue, maps them onto the machine 
modules present, and finds the optimal sequence of op- 

30 erations to produce the job. Note that for scheduling pur- 
poses, the Image Loader 98 is coordinated using the 
same Machine Module Interface as the machine mod- 
ules. The scheduler then coordinates the machine mod- 
ules, monitors their progress, and reacts to problems 

35 such as jams and determines the optimal recovery strat- 
egy. 

The machine modules describe themselves in 
terms of capabilities and constraints on those capabili- 
ties (e.g. can take in sheets and images and put out 

40 prints with a maximum throughput of 180 prints per 
minute). These are uploaded from each machine mod- 
ule into the scheduler where they are combined to form 
a model of the entire machine. Architecturally the 
scheduler requires no prior machine knowledge, and al- 

45 lows for machine modules to upload their capabilities 
and constraints at power up. However, for a particular 
product program implementation various optimizations 
may be made in order to lessen CPU and RAM require- 
ments. 

50 Some mark jobs are not completely provided at the 
beginning of a job, but rather are streamed in while the 
job is running. This Is called stream printing. The sched- 
uler is responsible for recognizing extensions to the tree 
as subtree extensions are streamed into it, and pruning 

55 th tree as the machine modules indicat that various 
nodes of the assembly tree have be n succ ssf ully de- 
livered. There may need to be som kind of bidding func- 
tionality For example, a print shop scheduler (a different 
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scheduler, at a much higher level) might query the Mark 
Facility Controller as to its ability to render a particular 
mark job. To validate the job without actually printing it, 
the bidding function would examine the machine graph 
(the description of the print machine configuration), val- 
idate that it could (or could not) do the job, and it so, 
submit a estimate of how long it would take, how soon 
it could start, etc. This would allow the print shop sched- 
uler to perform load balancing or job p re-validation to 
improve shop productivity. Note that when estimating 
the time to produce a mark job, the Mark Facility Con- 
troller cannot take into account unforeseen circum- 
stances like unexpected paper jams, etc. 

While the Image Path is not part of the Mark Facility 
Controller, the Mark Facility Controller makes assump- 
tions about its operation. The Mark Facility Controller 
treats images as work units to be scheduled (the same 
as sheets and compilations). The Mark Facility Control- 
ler expects modules sourcing images as work units to 
operate as proper Machine Modules and thus export the 
Machine Module Interface. Functions such as image 
buffer control, image processing, and consumption/gen- 
eration of Image formats are outside the scope of the 
Mark Facility Controller. 

The Mark Facility Controller also needs to support 
offline finishing. There are two classifications of offline 
finishing: 1) completely independent standalone finish- 
rs and 2) configurations of feeders and/or finishers. A 
Mark Facility Controller Is not needed in (1 ), but may be 
needed in (2). Therefore the Mark Facility Controller 
must be able to run on a platform suitable to this situa- 
tion. For example, it may be desirable to have the Mark 
Facility Controller run on a laptop which can be connect- 
ed to a configuration of feeders and finishers and coor- 
dinate them. 

A system of machine modules is modeled as a col- 
lection of transducers which have constraints, as shown 
in Figures 8 and 9, that specify their behavior Schedul- 
ing is accomplished by finding a sequence of transfers 
between the various transducer inputs and outputs that 
is consistent with the constraints. This is the essence 
that enables mix-and-match of Markers, Feeders, and 
Finishers, in particular, machine modules such as feed- 
ers, mark engines, and finishers are viewed as black 
boxes with portals which allow transfer units such as 
sheets, sets, plates, etc to enter or exit. Modules also 
have conceptual control signals which is used to specify 
desired capabilities such as simplex verses duplex, or 
staple verses bind. Modules export portals and control 
signals to the scheduler along with constraints. The con- 
straints identify the subspace of signals that can be ex- 
hibited by the black-box on Its portals. Every solution of 
the constraints corresponds to a feasible behavior of the 
black-box and every feasible behavior of the black-box 
corresponds to a solution of the constraints. 

Th sch duler cr ates a graph rep res nting all of 
the modules. 

For example, feeders 122, 124, and imag loader 



126 with specific constraints are connected to either or 
both of black and white mark engine 1 28 and color mark 
engine 130 as illustrated in Figure 8. Each of the mark 
engines includes specific constraints relative to a con- 

5 nection to complier/stapler 132 in turn connected to 
shrink wrapper 134 with associated constraints. De- 
pending upon the interconnection and constraints, cer- 
tain operations are acceptable and certain operations 
would fail. This interrelation can be illustrated by inter- 

10 connected transducers illustrated in Figure 9. For exam- 
ple, transducer 136 is connected to transducer 148, 
transducer 136 responding to constraints 138, inputs 
140 and control 142 to provide outputs 144 and 146. 
Output 146 is an input to transducer 148 in turn providing 

IS output 154 in response to control 152 and constraint 
150. 

When a print job is submitted, the scheduler creates 
a plan by solving the constraints and specifying the iden- 
tity and times of transfer along the edges of a graph rep- 

20 resenlation of module (the boundaries of the transduc- 
ers). The machine module descriptions that the sched- 
uler accepts are compositional, i.e. feeder, mark engine, 
and finisher descriptions can be merged at power-up 
time to form a single print machine description which can 

2S then be scheduled. 

Capabilities are a means of describing what a DOT 
machine module can do such as feed paper, simple 
mark, staple, etc. Capabilities are described in terms of 
work units input, work units output, and the relationship 

30 between the inputs and the outputs using universally de- 
fined keywords. Traditional means of defining what a 
machine module can do have limited their description to 
the end outcome (stapled, bound, etc) which Is Insuffi- 
ciently detailed to allow mix-and-match of markers, 

35 feeders, and finishers. 

A capability is expressed on a transducer such as 
a machine, a machine module, or a component within a 
machine module. The capabilities defined what the 
transducer does. The capability identifies which kind of 

^0 work unit is ente ring or exiting on which port of the trans- 
ducer It defines any constraints on timing of the work 
units (e.g. minimum 500 milliseconds between entering 
sheets), or attributes of the work units (e.g. paper size 
must be less than 17"), etc. It also defines the relation- 
's ship between the inputs and outputs in terms of work 
unit properties e.g. finishing changed, added, deleted, 
etc., e.g. the sheet exiting has all the same properties 
as the sheet entering, except the orientation is changed 
from face up to face down). 

50 The advantages over traditional methods of de- 
scribing such data include the following. Traditionally, it 
was simply stated that a machine module with a stapler, 
merely stapled, and referred to the DPA ISO 1 01 75 key- 
word STAPLE. However, actual machines differ widely 

55 in th physical details of accomplishing this op ration. 
Therefore, by simply saying STAPLE does not provide 
enough information to determine whether a collection of 
machine modules can actually produce the requested 
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job. For xample. one machine might receive the set 
face up. stapled and release the set face down. Another 
machine might do the same but release face up, another 
might not take sets in, but take sheets in, etc. Trying to 
describe all the different permutations using DPA-styled 
keywords quickly leads to an explosion of the number 
of keywords which quickly becomes unmanageable. 
Breaking the description into inputs, outputs, and the re- 
lationship between the inputs and outputs breaks the 
problem of describing what the machine does into small- 
er pieces which turn out to be easily rranageable. 

A Machine Graph, a directed graph data structure, 
as shown in Figure 9. is a means of representing a con- 
figuration of DOT feeders, markers, and finisher mod- 
ules. Traditionally, DOT machines were represented on- 
ly as the sum of their functionality (so many feeders op- 
tions, so much marking throughput, and so many finish- 
ing options) and have never attempted to represent to- 
pology. The nodes of the graph represent the machine 
module; the directed edge represented the paper/set/ 
etc flow between machine modules. Nodes may have 
muttiple ins and outs. By representing the machine as 
a graph, arbitrary configurations of nnachine modules 
can be expressed including modules with merges, forks, 
parallel paths, etc. Also, the marker-centric paradigm is 
no longer required - configurations can bo expressed 
which have multiple markers or no markers. 

In scheduling Document Output Terminals, commit- 
ting to some capabilities such as marking the front side 
of a page are interdependent on committing to other ca- 
pabilities such as marking the back side of the page as 
well. In the past such interdependencies were handled 
on an ad hoc basis. However, ad hoc methods generally 
do not support mix-and-match of arbitrary modules. A 
generalized concept called the commitment group, any 
collection of interdependent capability commitments is 
required. A commitment group is committed if and only 
if each capability commitment within the group is com- 
mitted. 

When any machine configuration is created, the 
Mark Facility Controller uploads the capabilities and 
constraints of each of the machine modules and exam- 
ines the constraints to uncover interdependencies. 
When a job is submitted and the Mark Facility Controller 
is coordinating its execution, the Mark Facility Controller 
identifies the commitment groups by referring to these 
interdependencies as it prepares to propose the capa- 
bilities to produce the job. Commitment Groups provide 
a generalized scheme for dealing with interdependen- 
cies, thus enabling mix-and-match of modules. 

In accordance with the present invention, there is 
provided an assembly tree to represent a document or 
job requirement. An assembly tree is a machine-inde- 
pendent representation of the structure of the physical 
document. An assembly tree is used to sp cify a docu- 
ment that is to be printed by a print engine. Traditionally 
machine-independent tree structures have been used 
at the Page Description Language level (e.g. Postscript. 



SPDL), but the assembly tree is diff rent in that it estab- 
lishes a machine-independent tre structure at the post- 
decomposition stage. Such a description is necessary 
to enable mix-and-match of document output terminals 
s (DOT'S). 

The assembly tree model is an extension of a model 
used in desktop publishing. Desktop publishing systems 
often organize data as trees. For example, text is made 
up of characters which nnake words, which in turn form 
sentences and paragraphs. Further, desktop publishing 
systems often distinguish between the text tree which 
describes just the text, and the format tree which de- 
scribes formats like font and line heights. To fully de- 
scribe a document, the text is "poured" into the format 
IS tree. 

Extending this concept, an assembly tree is defined 
which describes the production or assembly of the re- 
port. The separation of text, format, and assembly is 
very helpful because from the point of view of a print 
20 engine, text and format and other logical content can be 
entirely ignored. Further, tree definitions are inherently 
recursive, which leads to a description which is naturally 
extendible. 

With reference to Figure 10, there is illustrated an 
25 assembly tree structure to define a typical document. A 
typical document is generally a set of copy sheets made 
up of multiple images. For example, various images as 
illustrated at 202 are combined to provide sheets 212, 
214. 216. 218, and 220. It should be understood that 
30 any of the images 202 can be the product of several sub- 
images, For example, image 204 is shown as being a 
connbination of sub-images 206 and 208. As will also be 
understood, a sheet can be any combination of images 
and sub-images. For example, sheets 212 and 216 are 

55 illustrated, each as a combination of two images. It 
should be understood that a sheet is generally com- 
prised of a plurality of images and sub-images. 

A compilation Is a combination of multiple sheets. 
For example, copulation 222 is a combination of sheets 
212 and 214 and compilation 224 is a combination of 
sheets 216, 218. and 220. As shown, the compilations 
222 and 224 are for the purpose of stapling sheets. A 
compilation can also be a combination of sheets and 
other compilations. For example, compilation 226, for a 

-^5 shrink wrap operation, is a compilation of sheet 210, 
compilation 222 and compilation 224. As illustrated, the 
assembly tree nodes comprise images, sheets, and 
compilations. 

Compilations may have any number of groupings 

50 or off-spring. Sheets nnay have front and /or back imag- 
es. Images may have sub-images, recursively. All nodes 
may have properties such as size or weight. All nodes 
may have finishing specifications such as staple or trim. 
All properties and finishing identifiers are expressed 

55 through univ rsallyr gistered keywords. Note that whil 
the tr e is "post-decomposition" (the images are print 
ready), the tree is still machin independent. That is, the 
tree makes no stat ments concerning how the docu- 
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ments are to be produced (timing, production order, etc), 
only statements relating to the final output. The advan- 
tages over traditional methods of describing such data 
are that the assembly tree is highly expressive, machine 
independent, and extendible. The tree structure can ex- s 
press any kind of print engine job. This is a significant 
Improvement over traditional specifications which often 
had to be altered whenever a product program needed 
to add a new job type. The assembly tree specification 
is independent of any particular machine, its configura- io 
tions, and of it temporal constraints. This means the de- 
composer/print engine protocol doesn't have to change 
whenever the print engine changes. Because properties 
and finishing are expressed through keywords, new 
keywords can be added at any time, extending the 
space of expressible trees (traditionally, these have 
been hard-coded) The effect of the above is that the as- 
sembly tree enables true ESS/Print Engine plug-and- 
play. 

In accordance with the present invention, an as- 
sembly tree is used for describing a universal canonical 
representation of a physical document. Because it is 
purely descriptive, an assembly tree can be used to de- 
scribe a document that was scanned, a document that 
is to printed on a print engine, as well a document in 
intermediate steps between capture and mark. Tradi- 
tionally different formats have been used at each stage 
because no format was expressive enough to cover all 
areas. Because the assembly tree simply describes a 
physical document rather than prescribing various ac- 
tions to be taken, the assembly tree can be used in many 
interpretations. For example, when sent to a print en- 
gine, it can indicate a document to be printed. When re- 
ceived from a scanner, it can indicate a document that 
was scanned. 

The genesis of an assembly tree is any input stream 
that a machine can accept. The input stream may be a 
PDL stream, an incoming Fax, or a stream of scanned 
images-each of these streams may be accompanied 
by some amount of 'job level' information. A Mark Facil- 
ity and display are examples of consumers of assembly 
trees. Merge is an example of a component that con- 
sumes assembly trees and produces new assembly 
trees based on the input trees. The advantages over tra- 
ditional methods of describing such data include having 
a common data format and a single canonical form rep- 
resenting documents. Having a single canonical form 
greatly simplifies system software, eliminating the 
needs for features such as conversations. Also, estab- 
lishing a single canonical form for representing physical 
documents at the post-decomposed/image as bits cre- 
ates new opportunities for "plug-in components". For ex- 
ample, a 3rd party vendor might make a "Q-up" plug-in 
component that consumed assembly trees, and pro- 
duc d new ass mbty tr es that were 9-up versions of 
the input assembly trees. 

With reference to Figure 11 there is shown an ex- 
ample of the transf r of assembly tree representations 



between facilities. For example, block 230 illustrates the 
scanning of a document and conversion into the assem- 
bly tree format. At block 232, the scan document is 
transformed from a 1 -up to a 4-up document by suitable 
manipulation of the assembly tree. The document or im- 
age in the assembly tree format can then be displayed 
as illustrated at block 234, sent for editing for incorpo- 
ration into another electronic document as shown at 236 
or merged with other assembly trees as illustrated 238, 
Block 238 is also shown as receiving decomposed im- 
ages in assembly tree format at 242 and 240 to also be 
merged at block 238. The merged assembly tree can 
then be forwarded to a mark facility shown at 244 or filed 
as illustrated at 246. 

In accordance with the present invention, there is 
provided a generic means, a production tree, to repre- 
sent how a mark job is to be produced by a particular 
Document Output Terminal (DOT), a collection of mark- 
ers, feeders, and finishers. The product tree structure is 
generic and can be used for any mark job on any DOT 
Traditionally, such information was kept in ad hoc data 
structures customized to a particular DOT 

A production tree is a tree structure where the 
nodes represent capabilities of a DOT and the edges 
represent transfer of work units (images, sheets, and 
compilations) between various components of the DOT 
The structure of the production tree establishes which 
capabilities of which machine module will be used to 
produce which part of the job; the timings on the edges 
establishes when capabilities are be to executed and in 
what order. A production tree is generally built by taking 
an input mark job in the form of an assembly tree dis- 
cussed above, atong with a model of the DOT expressed 
in terms of components with capabilities and mapping 
the assembly tree onto the model's capabilities. 

Traditional methods of representing a document 
production plan generally have no means of accommo- 
dating a mix-and-match of various 3rd party markers, 
feeders, and finishers. The production tree enables this 
mix and match because of its generic means of relying 
on capabilities. The production tree is a central data 
structure in the Mark Facility architecture. Having a sin- 
gle representation across products allows for significant 
reuse among software that interacts with the production 
tree, in particular, a constraint-based scheduler. 

Figure 1 2 illustrates a typical production tree to rep- 
resent the manner of accomplishing a mark job require- 
ment. Assume an assembly tree represents sheet 1 to 
receive image 1 , sheet 2 to receive image 2, and sheet 
to receive image 3. the sheets 1 , 2, and 3 to be compiled 
and stapled. A production tree representation of this ge- 
neric assembly tree to achieve the result is illustrated. 
Specifically, Figure 12 illustrates the flow of the work 
units or images, sheets, and compilations are organized 
with appropriat timing indications to achieve the re- 
sults. Block 250 illustrates sheet 1 feed at 3700 millisec- 
onds and then image number 1 generated at 3800 mil- 
liseconds for nnarking at the appropriate marking ma- 
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chin at 4200 milliseconds as shown at block 262. 

In a similar manner, sheet number 2 is fed at 4700 
milliseconds and image number 2 generated at 4800 
milliseconds for marking sheet number 2 at 5200 milli- 
seconds as shown at block 264 and sheet number 3 fed 
at 5700 milliseconds with image number 3 generated at 
5800 milliseconds for marking the sheet number 3 at 
6200 milliseconds shown at block 266. A stack opera- 
tion or compiler shown at block 268 receives sheet 1 at 
5200 milliseconds, sheet number 2 at 6200 milliseconds 
and sheet number Sat 7200 milliseconds. Finally, a sta- 
ple operation is illustrated at block 270 at 7900 millisec- 
onds. 

In general jobs are submitted to a DOT in terms of 
assembly trees which specify only what must be pro- 
duced, not how to produce it. However, sometimes op- 
erators need more control over the manner in which the 
job is to be produced (e.g. only use paper in tray 6, use 
stapler A, not stapler B. etc). Because a production tree 
represents a plan of exactly how a mark job is to be pro- 
duced by a particular DOT as discussed above, a partial 
production tree can be used as a generic means to spec- 
ify parts of the job which the operator wants to specify. 
Previously, there has been no generic means to accom- 
plish this type of job designation. 

In accordance with the present invention, when a 
mark job is submitted, in addition to the assembly tree, 
the submitter may optionally include an untimed produc- 
tion tree (i.e. a production without timing defined on its 
edges). The included production tree describes exactly 
how only certain portions of the job are to be accom- 
plished. Typically the production tree is a partial produc- 
tion tree, but it may be a complete production tree (in 
that case, the submitter has identified exactly how every 
aspect of production Is to be carried out). The Mark Fa- 
cility uses the submitter's production tree as a constraint 
in building its complete production tree capabilities in 
the complete production tree must match the capabili- 
ties specified in the submitters production tree. If the 
submitted production tree was partial, unspecified parts 
may be achieved using whatever capabilities the Mark 
Facility chooses. 

How to specify machine-dependent actions in pro- 
ducing a job has traditionally been ad hoc and machine- 
dependent. Such means can not support mix-and- 
match of various markers, feeders, and finishers. Using 
the Production Tree to specify machine dependent ac- 
tions is based on the generic concept of capabilities and 
components, and supports mix-and-match. 

Traditionally, all DOTs have been monolithic, and 
therefore a diagnostic procedure simply asked the DOT 
to do a particular action such as feed 1 0 sheets and take 
timing measurement along the paper path. However, in 
a mix-and-match context, a mark engine's paper path 
and the feeders which supply paper may be in differ nt 
mix-and-match machine modules which could be con- 
figured in any arbitrary configuration. Therefor , a mark 
engine paper path diagnostic cannot know when sh ets 
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should be f ed. and similarly, neither can the mark en- 
gine. However, in accordance with the present inven- 
tion, by supplying a partial production tree to the Mark 
Facility which specifies what paper is needed and when, 

5 the Mark Facility can determine when various feeders 
in other machine modules need to feed in order to satisfy 
the need of the diagnostic routine. 

That is. in order to execute a diagnostic routine on 
a machine nrxxiule which requires cooperation from oth- 

10 er machine modules, a diagnostic service submits an 
untimed partial production tree to the Mark Facility. The 
Mark Facility then coordinates the other machine mod- 
ules in order to meet the requirements expressed in the 
production trees. Previously, there was no means to 

'5 achieve diagnostics requiring multiple nnachine module 
cooperation in a mix-and-match context. How to specify 
diagnostic actions has also traditionally been ad hoc and 
machine dependent. Such means, likewise, do not sup- 
port mix-and-match markers, feeders, and finishers. Us- 

20 ing the Production Tree to specify such actions in other 
machine modules is also based on the generic concept 
of capabilities and components and provides more ver- 
satile and selective diagnostics. 



Claims 

1. A method of operation of an electronic image 
processing apparatus in a diagnostic mode, the 
electronic image processing apparatus comprising 
a controller (74) and a plurality of machine modules 
(104,106.108), each of which includes an associat- 
ed processor electrically connected to the controller 
(74). each of the processors storing data related to 
operational capabilities of the associated module, 
including; 

receiving in the controller (74) a diagnostic re- 
quirement having a module independent ele- 
ment and a module specific element, 
interrogating the machine modules 
(1 04, 1 06, 1 08) to determine the interconnection 
and capabilities of each of the machine mod- 
ules (104,106,108). 

setting up the modules identified by the module 
specific element. 

converting the module independent element In- 
to a selection of modules to support the mod- 
ules identified by the module specific element, 
and 

coordinating the machine modules to complete 
the diagnostic requirement. 

2. A method as claimed in claim 1 , wherein the module 
ind pendent and modul specific elements ar con- 
verted into a capability and timing format for driving 
the machine modules. 
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format into a timed relationship of a selected 
set of modul s to initiate the diagnostic routine, 
and 

coordinating the operation of the selected set 
of modules to complete the diagnostic routine. 

A method as claimed in claim 6, including the step 
of defining each of the modules with Inputs and out- 
puts with said constraints and, optionally, providing 
a timed sequence of matched inputs and outputs 
between modules. 

A method of operation of the image processing ap- 
paratus in a diagnostic nnode, the image processing 
apparatus comprising a controller and a plurality of 
machine modules, each of the modules including 
an associated processor electrically connected to 
the controller, each of the processors storing data 
related to operational constraints ot the associated 
module, including: 



3. Am thod of initiating a diagnostic procedure on an 
electronic image processing apparatus, the elec- 
tronic image processing apparatus comprising a 
controller (74) and a plurality of modules 
(104,106,108), each of the modules including an 5 
associated processor, each of the processors stor- 
ing data related to operational constraints of the as- 7. 
sociated module, a bus for interconnecting the proc- 
essors to the controller for directing the operation 

of the modules, including: 

receiving from each of the processors the data 
related to the operational constraints of each 8. 
associated module, 

defining each of the modules with inputs and ^5 
outputs having said constraints, 
interrogating each of the processors to deter- 
mine the geometrical relationship of the inter- 
connection of the modules, and 
responding to the data related to the operation- 20 
al constraints of each of the processors and to 
the geometrical relationship of the interconnec- 
tion of the modules for providing a timed se- 
quence of matched inputs and outputs between 
modules to Initiate the diagnostic procedure. 25 

4. A method as claimed in claim 3, wherein the con- 
straints include attribute constraints and/or time 
constraints. 

30 



5. A method as claimed in claim 3 or claim 4, wherein 
the step of initiating the diagnostic procedure is in- 
dependent of a particular configuration of the plu- 
rality of modules, and/or wherein the step of provid- 
ing a timed sequence of matched inputs and out- 
puts between modules includes the step of provid- 
ing electrical and mechanical events to accomplish 
the matched inputs and outputs. 



receiving in the controller a diagnostic require- 
ment having a module independent element 
and a module specific element, 
interrogating the machine modules to deter- 
mine the interconnection of each of the ma- 
chine modules, 

converting the module independent and mod- 
ule specific elements into a selection of time 
compatible modules to support the diagnostic 
requirement and 

coordinating the machine modules to complete 
the diagnostic requirement. 

55 9. A method as claimed in claim 8, wherein the module 
independent and module specific elements are con- 
verted into a constraint and timing format for driving 
the machine modules. 

10. A method of operation of the image processing ap- 
paratus to complete a given diagnostic request, the 
electronic image processing apparatus comprising 
a controller and a plurality of modules, each of the 
modules including an associated processor, each 
of the processors storing data related to operational 
constraints ot the associated module, a bus for in- 
terconnecting the processors to the controller tor di- 
recting the operation of the modules, including: 

receiving from each of the processors the data 
related to the operational constraints of each 
associated module, 

interrogating each of the processors to deter- 
mine the geometrical relationship of the inter- 
connection of the modules, and 
r spending to the diagnostic request and to the 
data related to the operational constraints of 
each of the processors for selecting a set of 



6. A method of initiating a diagnostic routine in an elec- 40 
tronic image processing apparatus comprising a 
controller and a plurality of machine modules, each 
of the modules including an associated processor 
electrically connected to the controller, each of the 
processors storing data related to operational ca- 4S 
pabilities of the associated module, including: 

identifying a given diagnostic routine in an un- 
timed format, 

interrogating the machine modules to deter- 50 
mine the interconnection and operational capa- 
bilities of each of the machine modules, Includ- 
ing receiving data related to the operational 
constraints of each associated module, 
analyzing the diagnostic routin in the untim d 55 
fomnat and the operational constraints of each 
associated module, 

converting the diagnostic routine in the untimed 
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